home *** CD-ROM | disk | FTP | other *** search
/ Languguage OS 2 / Languguage OS II Version 10-94 (Knowledge Media)(1994).ISO / gnu / objcissu.lha / smalltalk < prev    next >
Internet Message Format  |  1993-03-01  |  5KB
  1. Date: Wed, 16 Sep 92 14:31 PDT
  2. From: michael@stb.info.com (Michael Gersten)
  3. To: Geoffrey S. Knauth <ucla-cs!marble.com!gsk@CS.UCLA.EDU>
  4. Subject: Smalltalk
  5.  
  6. Actually, not smalltalk, but a language called Actor on the IBM PC
  7. under windows.
  8.  
  9. Roughly, Actor is based on smalltalk, and inspired by it; the core of
  10. the language is a forth engine, highly optimized for accessing
  11. instance variables of objects and elements of an array. (In fact,
  12. there's no difference between accessing the nth element of an array
  13. object, or the nth instance variable of other objects after the
  14. compiler has gotten through with it. Of course, a class can either
  15. have instance, or indexed variables, but not both).
  16.  
  17. The scheme I described is very similar to what Actor uses, but does
  18. not go into the specifics and details. (Lets say I'm worried about
  19. "contaminating" the list and opening the FSF to a lawsuit).
  20.  
  21.         Michael
  22. --
  23.         Michael Gersten        michael@stb.info.com
  24. HELLO! I'm a signature virus! Join in the fun and copy me into yours!
  25. ex:.-1,. w $HOME/.signature
  26.  
  27. From Steve_Naroff@next.com Wed Sep 16 19:35:55 1992
  28. Return-Path: <Steve_Naroff@next.com>
  29. Received: from albert.gnu.ai.mit.edu by carrara.bos.marble.com (NX5.67c/Marble-3.0)
  30.     id AA03805; Wed, 16 Sep 92 19:35:48 -0400
  31. Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
  32.     id <AA04796@albert.gnu.ai.mit.edu>; Wed, 16 Sep 92 19:18:44 -0400
  33. Received: from NeXT.COM by life.ai.mit.edu (4.1/AI-4.10) id AA23228; Wed, 16 Sep 92 19:18:39 EDT
  34. Received: from nomad by oz.NeXT.COM (NX5.67c/NeXT0.1-Aleph-bf)
  35.     id AA21701; Wed, 16 Sep 92 16:18:04 -0700
  36. From: Steve_Naroff@next.com (Steve Naroff)
  37. Message-Id: <9209162318.AA21701@oz.NeXT.COM>
  38. Received: by nomad.next.com (NX5.67c/NX3.0X)
  39.     id AA02690; Wed, 16 Sep 92 16:17:55 -0700
  40. Date: Wed, 16 Sep 92 16:17:55 -0700
  41. Received: by NeXT.Mailer (1.87.1)
  42. Received: by NeXT Mailer (1.87.1)
  43. To: dennis_glatting@trirex.com
  44. Subject: Re: Automatic input/output, persistence
  45. Cc: uunet!lehigh.edu!gdb0@uunet.uu.net (GLENN BLANK), gnu-objc@prep.ai.mit.edu
  46.  
  47.  
  48. > Shouldn't the object itself be responsible for what it contains and what is relevant rather than an outside entity? 
  49.  
  50. Absolutely...here are three reasons that come to mind:
  51.  
  52. 1) Control over what is persistent (vs. transient). This feature can dramatically effect the size of the composite object (and associated cost to activate it from disk).
  53. 2) Data that needs to be converted on read/write (e.g. ports, file descriptors...i.e. any data that has different meanings across process boundaries).
  54. 3) Version control for converting old objects to new objects...the object database folks call this "schema evolution" (sounds fancy). NeXTSTEP objects can read old versions of themselves without any problem...we don't force the application to evolve all nib files in concert. This flexibility is very hard to achieve without involving the object.
  55.  
  56. Schemes that do not have these capabilities are usually not very useful for building real applications.
  57.  
  58. snaroff
  59.  
  60. From stb!michael@cs.ucla.edu Wed Sep 16 23:33:21 1992
  61. Return-Path: <stb!michael@cs.ucla.edu>
  62. Received: from albert.gnu.ai.mit.edu by carrara.bos.marble.com (NX5.67c/Marble-3.0)
  63.     id AA04081; Wed, 16 Sep 92 23:33:18 -0400
  64. Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
  65.     id <AA06652@albert.gnu.ai.mit.edu>; Wed, 16 Sep 92 23:11:01 -0400
  66. Received: from aeneas.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA29959; Wed, 16 Sep 92 23:01:53 EDT
  67. Received: from Kona.CS.UCLA.EDU by aeneas.MIT.EDU (5.61/4.7) id AA15838; Wed, 16 Sep 92 23:01:50 -0400
  68. Received: from stb.UUCP by kona.cs.ucla.edu
  69.     (Sendmail 5.61d+YP/3.20) id AA16723;
  70.     Wed, 16 Sep 92 20:00:31 -0700
  71. Received: by stb.info.com (/\==/\ Smail3.1.20.1 #20.13)
  72.     id <m0mVBlL-0005OXC@stb.info.com>; Wed, 16 Sep 92 19:38 PDT
  73. Message-Id: <m0mVBlL-0005OXC@stb.info.com>
  74. Date: Wed, 16 Sep 92 19:38 PDT
  75. From: michael@stb.info.com (Michael Gersten)
  76. Received: by NeXT Mailer (1.63)
  77. To: ucla-cs!prep.ai.mit.edu!gnu-objc@cs.ucla.edu
  78. Subject: Auto persistance of objects: A comprimise
  79.  
  80. Here's a possible solution:
  81.  
  82. If you don't want Object to have a default way of reading and writting all objects, why not have some tool that reads a .h file, and generates a read: and write: method to do default archiving?
  83.  
  84. This way all objects get one by default, and you can customize it if you want to.
  85.  
  86.         Michael
  87. --
  88.         Michael Gersten        michael@stb.info.com
  89. HELLO! I'm a signature virus! Join in the fun and copy me into yours!
  90. ex:.-1,. w $HOME/.signature
  91.  
  92.